An awkward aspect of this approach for adding datetime accessor aliases, which was present before this PR, is that the name of the resulting DataArray is inconsistent with the name of the alias, e.g. in the current version of xarray:

>>> times = xr.date_range("2000", periods=10)
>>> xr.DataArray(times, dims=["time"]).dt.weekday
<xarray.DataArray 'dayofweek' (time: 10)> Size: 80B
array([5, 6, 0, 1, 2, 3, 4, 5, 6, 0])
Coordinates:
  * time     (time) datetime64[ns] 80B 2000-01-01 2000-01-02 ... 2000-01-10

A current consequence of this in this PR is that the name of these DataArrays will change:

>>> xr.DataArray(times, dims=["time"]).dt.weekday
<xarray.DataArray 'day_of_week' (time: 10)> Size: 80B
array([5, 6, 0, 1, 2, 3, 4, 5, 6, 0])
Coordinates:
  * time     (time) datetime64[ns] 80B 2000-01-01 2000-01-02 ... 2000-01-10

We could rename to always match the old names if we want to be as conservative as possible, but it feels more intuitive for the name of the DataArray to match the name of the accessor attribute. Should we address this as part of this PR as well?

Since these properties are just one line of code, it doesn't hurt to add the aliases as "real" properties back. This also allows us to depreciate it as well (do we want to?).

Yes, my second suggestion would involve defining the aliases as their own independent properties to give us control over the name of the resulting DataArrays. My feeling is that we could consider the name mismatch a "bug" which we could fix without a deprecation cycle, but I am open to opinions from others.